[レポート][Dev-05:Mobile] 900万ダウンロードアプリ『Gunosy』を支える大規模モバイルプッシュ通知基盤 #AWSSummit

こんにちは！おおはしりきたけです！ 今回は、900万ダウンロードされているニュースアプリのGunosyさんがAmazonSNSを使ったモバイルプッシュの配信基盤のお話になります

セッション情報

• セッション名：900万ダウンロードアプリ『Gunosy』を支える大規模モバイルプッシュ通知基盤
• スピーカー：株式会社Gunosy 榎本敏丸氏

Gunosyのプッシュ基盤

Gunosyとプッシュ通知

• モバイルプッシュ通知はDAUを支える重要要素
• プッシュ通知はGunosyアプリを開くきかかけを与える　→ユーザーリテンション
• プッシュ通知結果がDAUを左右する
  • プッシュの内容により、DAUの増減がある

Pushは大きく2つ

1.定時プッシュ

• 朝・昼・夕方・夜の決まった時間のプッシュ通知

2.速報プッシュ

• 速報性のある即時送りたいプッシュ通知
• 例：大きな地震、大きな事件

定時プッシュ

• いつ？：ユーザーが設定した時間
• 誰に？Push通知を設定したユーザーに
• どれくらいで：負荷をかけずできるだけ短時間で
• 何を？適切なタイトル・内容でプッシュ通知を送る

定時プッシュはゆるやかに打つ

速報プッシュ

• いつ？大きな事件・事故が起こった瞬間
• 誰に？Push通知を設定したユーザー
• どのくらい？できるだけ短時間で
• 何を？適切なタイトル・内容でプッシュ通知を送る

Gunosyプッシュ通知の歴史と変遷

• 1期：ローカルプッシュ
• 2期：リモートプッシュ
• 3期：本格リモートプッシュ
• 4期：パーソナライズドプッシュ

第1期：ローカルプッシュ時代

• 設定された時間にニュースが届きましたという定型文

結果

• プッシュ通知をキッカケにアプリを立ち上げるユーザーが増加
• まずまずの開封率
  • 定型文ではニュースの内容がわかない
  • 毎日同じ時間に定型文が送られてくるので、ユーザーが飽きたのではないか？

第2期：リモートプッシュ時代

• AmazonSNSの導入
• ニュースが更新されました「ニュースタイトル」ほかという通知
• ローカルプッシュ→リモートプッシュの移行

結果

• プッシュの開封率は大幅アップ
• プッシュ通知→DAU向上
• 日によってDAUが爆発的に伸びた。
• 現在では当たり前のリモートプッシュだけど当時は少なかった。

雑なプッシュ通知運用

• ・開発者がサーバーにSSHログインしてプッシュのためのコマンドを打つ
• ・プッシュ通知管理画面が不安定

第3期：本格リモートプッシュ時代

• SNSを用いたリモートプッシュ通知の本格運用
• 大規模プッシュに耐えるアーキテクチャをきちんとゼロから考える

定時プッシュ

• モバイルエンドポイント取得
• Redisにエンキュー
• ワーカーにデキュー
• SNSにPublish

1インスタンスあたりのPushは、1秒間に400Pushできる。インスタンスサイズはt2micro。インスタンスサイズが小さいので、１インスタンスあたりの価格が1時間0.02$と非常にお得

• 時間帯で増減するインスタンス
• OpsWorksで運用を行っている。

プッシュアーキテクチャ

• Redisを用いたシンプルなpub/sub
• スケーラブルなプッシュワーカー　ワーカーをスケールさせれば早く打てる。
• タイムベーズなインスタンスで低コスト運用

速報プッシュ

管理画面をRailsで作っている

プッシュ管理画面

• プッシュ内容・タイトルを設定する管理画面
• Rails +Sidekiq
• Sidekiqワーカーがエンドポイント取得、Redisにエンキュー

モバイルエンドポイント取得SQLが遅かった。クエリだけで10分かかっており、高速化対策を行った。

高速化対策を行った速報プッシュのアーキテクチャ

DataPipelineで定期的にエンドポイントのデータを取得しS3に配置する構成。結果10分から15秒になった。

第4期：パーソナライズドプッシュ時代

• ユーザーの趣向に応じたプッシュ通知
• 絶賛開発中！

パーソナライズドプッシュのアーキテクチャ構成

• Djangoでプッシュリクエスト受け付け
• Celeryでタスクキューイング
• 疎結合なワーカー郡

GunosyでのAmazonSNS利用事例

SNS用語

• Device Token：アプリケーションの識別子。各プラットフォームが発行
• Endpoint Arn：Device Tokenから生成されるモバイルエンドポイント、SNSではこのモバイルポイントを使ってプッシュが送られる

SNSのメリット

APNS/GCMの各プラットフォームのAPIを抽象化、プラットフォームごとの違いを意識する必要がない

価格

• 100万リクエスト/月無料
• 超過する場合100万リクエスト毎に$0.5

デバイストークン管理の難しさ

1.デバイストークンが変わる（Android)

デバイストークンはどう変わる？

• アプリを再インストール
• データを削除された時
• アプリをバージョンアップした時

デバイストークンは定期的に更新する必要がある。

ポイント ・デバイストークンを定期的に更新 ・更新されたデバイストークンを元にバッチ側で再度モバイルエンドポイント生成

2.Enable/Disble制御

弊社のこの記事の紹介

SNSでは何度か通知に失敗した場合endpointがdisableになる一度disableになると以降PublishしてもAPNSが叩かれることはない どうするか？ 寝ているEndpontArnを起こす(Re-enable処理）

3.DisableなEndpointArnの削除

• モバイルエンドポイントのムダなPublishはしたくない
• SNSへのPublish時にdisableなEndpointArnは削除

＃SNSベストプラクティス

• デバイスごとにデバイストークンを管理
• 定期的にデバイストークンをチェックして更新
• モバイルエンドポイントのRe-enable処理
• disableなEndpointArnは削除してムダなPublishは控える

感想

弊社でもSNSはよく利用しますが、大規模プッシュのインスタンスにt2microを利用しているというのは衝撃でした。t2microでもSNSへのPublishだけなので処理的には大きくないのと、スケーラブルにして配信管理をすることができるので、クラウドのメリットを非常に感じることができました。現在実装中のパーソナライズドプッシュもリリースされたらまたお話が聞きたいです！